RLECViewer: Custom Clevo Fan Control

Original post (in Chinese): http://tieba.baidu.com/p/4872453181

The original program is in Chinese, I translated it into English (at least for the most part).

Source code: https://github.com/duguzuyang/RLECViewer

Installer: https://github.com/duguzuyang/RLECViewer/raw/master/Install/Product/RLECViewer.exe

Uninstall Clevo Control Center first, then install this program.

Tested on Clevo P751DM2, Windows 10 1803 w/ UEFI.

Warning: Use at your own risk, no warranty whatsoever.

This software was originally designed to make the laptop run quieter during normal daily usage, since the original fan curve is pretty aggressive in lighter tasks.

 

Nice. I've only been waiting for this for like... the past seven years.

Will be testing this.

 

So it works ok on W110ER (i7-3630qm/GT650M), which has only one fan. Lots of trial and error to find values that work for the individual laptop, for example this was on minimum actual fan speed until "45%" in the app. There's also a delay of a few seconds so if you set the % fan speeds too far apart you will end up with an annoying off-on cycle - I will be interested in trying it in the P870DM3 to see whether the fan speed ramp will be gradual like it is on the stock profiles

On initial use I'd request more customisation (to set the number of steps and edit the temp thresholds), and multiple profiles that can be quickly changed (tied to hotkeys)

 

Many will be very interested, waiting for any updates, thanks in advance.

 

Nice finding, thank you for sharing.

 

damn, that is some crazy stuff! clevo users have been asking for something like this for yeaaaars....

 

@John@OBSIDIAN-PC, we are waiting for an answer from your side)

 

Why should i answer anything? The more solutions we have the better! Hurray for this.
I´ll keep doing my own version which hopefully will have more options then this one. But this seems cool already, way to go!

 

Waiting patiently for yours!
The above is replicating Clevo's own internal (read short therm) testing software and also has like zero safety net in case it looses control over the FANs.
It'll smoke a system if user sets wrong values or it looses control and they no longer spin up higher with increased heat. Hence we used to call it the RMA Tool.

 

I actually have not looked at that code, so i did not knew that.
It´s weird that most of the solutions take that path.
If you look at Control Center there is already a really cool DLL that exposes to WMI lot´s of methods for all sorts of stuff, setting fan / setting keyboard colors / etc.
My method is using just that, with a high performance API i talk directly with the same dll that CC does.
Users will be able to use the app with CC running or for those without CC the app will prompt to install only the needed dll. The app will be modular enough to use different methods for getting temperatures and loads too, either use Open Hardware Monitor or any other with wmi methods.

So here is where i am at the moment:

For "Automatic Modes" you can create and name 3, each will have a lookup table that can be edited with any file editor or in the app itself:
(Note: This is a Debug version, no theme / colors / styling )



Those "weird" numbers will be 0 to 100% in the user version.
But it´s basically a lookup table, CPU Temp x GPU Temp.
Useful for brands (like us) to create different automatic modes for each laptop model.


As for the Manual Mode:

You will have 8 ranges setup for CPU and GPU (individually).
You can set ranges and fan speed for each range.

At the moment i´m trying to figure out how to do some smart ramping and to give the user ramping multiplier slider, maybe i will call it "Ramp Up Speed" and "Ramp Down Speed"... not sure.

 

Looking good. Maybe use a ramp curve like (moving the entire set like for GPU pverclocking) and an option to set fixed steps from one value to the next (e.g. 10c or 10%).

Just make sure that at least everything above 90c sets 100% and that user are entirely locked out to change that.

 

Yeah it still needs work in the UI to make it something easy to use.
The ranges knobs are actually cool, if you rotate one above the min. value of the next knob then the next knob rotates automatically, same for lowering ranges, makes it REALLY easy to use.
As for that 90ºC security it is already done and working in that security tab on the left.

 

@ John@OBSIDIAN-PC

That looks very nice, is this open for download (beta testing)? As far as I understand Prema correcly, the software in OP posts can lose fan control and will likely kill machines in the long run but your solution looks very nice.

 

My solution in not ready for beta testing yet.
Beta Testing milestone doesn't even have a date yet. I´m adding a senior programmer to this team and we will discuss schedules tomorrow.
In the meanwhile most of the engine / ui is done so i might have to back out a bit, there is so much going on around here, somehow i got myself doing our new website alone... i still need to code new internal management modules (which are missing), link everything together (client side / management / warehouse / production / new website), i need to update obsidian tools with new models, i need to update a ton of bios, and i still find myself needed in the production line more often then expected. We are barely able to keep our online chat open (it´s offline most of the time). Yes this means i need to hire/train new staff...
I might just go crazy before i do all that.
On the good side, sales are going up... on the down side... no vacations this year...

 

Sad to hear really. Guess I'll have to work on this myself. I didn't even consider the possibility to use the dll to make a custom fan profile tool. Guess sometimes the most obvious solutions are hard to find if you overthink some things.

 

This looks very interesting, can't wait to become a beta tester.

I believe this program is also using the DLL files from Clevo.

 

Ramping:

Check box "Smooth Fans" which instead of only setting the fan speed to the values AT the thresholds, instead sets it by:

X = (current temp - lower temp) / (upper temp - lower temp)

Where "upper" and "lower" are the data points (temp+fan) immediately above and below the current temperature

Formula generates X, a fraction between 0.0 (at lower temp/fan) to 1.0 (upper temp/fan)

Set fine grained fan speed with: desired fan speed = lower fan + X * (upper fan - lower fan)


You could generate the an entire fan curve this way with only two data points, silent or aggressive modes could be set by applying an exponent to X (<1 for more aggressive e.g. X^0.8; >1 for more silent e.g. X^1.2) to move away from a straight linear temp / fan relationship.

 

Good idea, you are welcome to modify the code and build your own version.

 

Looks great. Thanks for sharing!

 

Just for reference, I had done something similar for Linux quite a while ago: https://github.com/davidrohr/clevo-indicator (with some discussion here: https://www.techinferno.com/index.p...ware-mod-linux-fan-control-for-clevo-p775dm3/).

And some remarks:
- Since in some clevo models the heatpipes of CPU and GPU are connected, I give feedback from the CPU temperature to GPU fans and vice versa. I.e. if one gets really hot but the other doesn't, both fans will spin fast.
- When undervolting + underclocking the CPU to keep the laptop silent at night, I was facing the issue that under high load (even though the CPU did not get hot) the system would crash. I assume some other components like chipset or voltage regulators overhead since the fans do not go fast with the CPU relatively cool.
- I was indeed facing the issue that the service that sets the fan speed might crash, and the fans might be stuck at a low speed. For this I am running a second independent service that monitors the first one, but still this is no good solution. It would be better to hack everything in the EC firmware and control the fans from there.
- You have to make sure to reset the fans to automatic before reboot. Otherwise, when you restart and kill the service, the fans might be stuck at low speed. When the service does not come up after reboot, the system will overheat.
- The EC reports bogus values from time to time. So you should use some kind of filter and not use the current temperature direcly (running average, or in case of significant difference, just query the temperature again).
- I have some fixed set points like you (x% fan speed at y° deg CPU / GPU temperature) and use linear interpolation in between. No need to use splines or more complicated curves in my opinion.

And finally some questions:
- How do you obtain the GPU temperature (I didn't check your code yet). I had the problem that I could not read it reliably from the EC since the temperature there seems to be stuck sometimes. Therefore I am querying it from nvidia-smi right now.
- Have you found out how to return the fan speed control to automatic? It works by pressing fn-1, but I didn't found an EC register to write to that would reset it to auto. From the images it likes like you can reset to automatic.
- @John@OBSIDIAN-PC: will/is your application open source as well?

 

I´m not sure if your questions are directed at me or not.
As for my app it monitors 4 things: CPU Temp / CPU Load and GPU Temp / GPU Load, i´m now adding also Fan RPM (although i dont really need it).
I never had a single stuck fan or crash with my engine, as i said before i only use the already included .dll from CC.
The advantages of the app im making is that If you quit the app it sets it back to Automatic Fan, it is modular and it can get temp and load values from any of the good indicators out there (im using Open Hardware Monitor).
It´s using the CLEVO exposed methods so you can use it with Control Center at the same time.
It´s really high performance.

As for setting fans back to auto you can use setFanAutoDuty() with wmi method, the trick is to first set the fans to a manual minimal value, do it 2 or 3 times to be sure, and only after that set to auto.

A lot of work is being put in the table creation / edition for the Automatic Modes, this will be a bliss if i want to adjust or create modes for different laptop models. You can edit the tables at ease, restore them, test them, etc

To be honest there is only ONE thing missing to be able to release the first beta, and that is the most important thing, i´m still fighting to fully understand the conversion method for the fanduty.

In theory you have up to 3 fans which can be controlled individually, and you can send a uint32, we are currently working on the math to go from percentage to actual fan duty... After this the first beta is getting released as everything else is done.

If you look here:



This is where you edit the Automatic Modes, i love this to create the modes, most of this actually comes from Motorcycle ECU code i did some while back ... BUT, if you look at the value that´s an actual fanduty value, and it should be something like percentage, you should be able to type 100%100% (100% CPU and 100% GPU) for instance.
But i need to finish my class to convert from percentage to actual fanduty, and it´s not linear at all. You can test values and do a table like that, but they still do not make sense.

I was expecting something like:
For 50% Fan1 and 50% Fan2 we should do something like (50 * 255) + (50 * 255), something in the lines of that, i´ve tried all types of conversion, and maybe i should just look at someone else code, but i really DONT want to do that, in the past i had bad experiences with that, looking at someone else code will always influence you, and the last thing i want is to be accused of stealing anything.
All code here is 100% original from scratch.

As for making it opensource it´s hard man, we are a small company, if we do not bring income we cant keep doing stuff like this. Our purpose in doing software like this is either income or making people buy our brand because of it. Not sure if you you guys know this, but we are still a 5 people company. What i will for sure do is make a free version just like i did with the Drivers tool (which is going to be re-done soon too). I´m ok about adding anyone to our team and even paying for code work, to be honest up to this point the code is 100% mine, there´s not a single line that i personally did not do, everyone else around here is doing other stuff (hopefully that is changing). Yesterday i finish setting up the working environment for a new Senior Programmer who is joing this, so i expect a lot of great things

 

Thanks for the extensive reply. I get your point of keeping the code to yourself, even though I favor open source.

I am not 100% sure if I can help you with the duty cycles. What is written to the EC register in the end is not an uint32, but just 8 bit integer 0 = 0%, 255 = 100%. I am not sure if there is any additional conversion in the clevo DLL.

By the way, which clevo DLL are you using for the wmi method? The application in the OP uses a ClevoEcInfo.dll, but that one does not expose the setFanAutoDuty() function, it has a setFANDutyAuto function (or is it the same and did you misspell the capitalization above?).
(The application in the OP ships also with an ecview.dll, but would use that only as fallback if ClevoEcInfo.dll is not present.)

I started disassembling the ClevoEcInfo.dll, but at least it was not apparently clear what it does. Will need some more time. I am interested what is send to the EC on the low level to trigger the automatic mode, since I want to include that in my linux app. Unfortunately, you won't be able to help me, since you use the windows DLL and don't talk to the EC directly.

Coming back to your fan duty cycles. I'd suggest to try the following 3 things:
- Send just 8 bit integers (0 to 255) and see if that sets 0% to 100% fan duty.
- For endianess reasons, try 0x00000000, 0x01000000, ..., 0xFF000000.
- Read the old 32 bit value, and replace one of the four 8 bit blocks by 0x00 to 0xFF.
If you confirm which DLL method you are using, I might be able to tell you more.

 

@ John@OBSIDIAN-PC, For me as a person far from programming, it's nice to read such answers as yours. I'm looking forward to the release to support your team with the purchase.

 

I sent you a PM.
By the way for years my personal app version for Linux uses all your code
I started with it and kept adding stuff like automatic fan profiles, made it into a VALA indicator for ElementaryOS and all sorts of stuff
As i said before i don´t like to use someone else code, unless it´s for personal use...

When i started doing this one for windows, everything uses a different approach, no direct talking with EC, not getting values from EC, nothing is the same


And yes it is indeed setFANDutyAuto.

Looking at my class, i always had to do this:

clevoset->setfanduty(1, 1134165000);
clevoset->setfanduty(1, 1134165);
clevoset->setfanduty(1, 80);
clevoset->setfanduty(1, 50);
clevoset->setfanduty(2, 21);
clevoset->setfanduty(2, 11);

That´s the same as:

// For some strange reason sometimes when going into auto mode sometimes one fan gets stuck
// Over the years i found that by first setting a lower manual mode like this:

SetFanDuty(1134165);
SetFanDuty(80);
SetFanDuty(50);

//And then setting it to Auto twice like this:

setFANDutyAuto(21);
setFANDutyAuto(11);

//Works.... don´t ask me the logic behind it....

 

Sounds a lot safer not to be constantly poking the ECU directly.

 

Update, it seems our new developer took only one afternoon to solve the fanlogic math... damn i feel like a total noob now
Well the most difficult part is done so expect progress very soon

 

Haha, it's alright happens to the best of us. Sometimes it's better to have another's eye to see where we might have miss something or get stuck. Looking forward to testing and a purchase!

 

For the record I tried this on the DM3. With 3 fans manually selected and all manual speed settings, the fans were controlled properly.

However, the algorithm didn't update fast enough to stop thermal throttle in the first few seconds after starting a full on maximum overclocked workload (4.8ghz at ~1.4V drawing in excess of 110W) that would otherwise stabilise temps in the low 90s

Then again, neither does the 'automatic' stock Clevo profile since the fan speed ramp up is too gradual

 

This is amazing! I've been searching/waiting ~6 years for this. I promptly cranked the fans up to 100% on my W110ER. Now my stomach doesn't burn and the touchpad doesn't malfunction from the excessive heat. 50c is so much more comfortable than 75c.

 

It is, and a 25 Celsius drop is nothing to sneeze at, but then 75 Celsius is, honestly, quite good, all things considered.

 

Other than a user setting the fan's values too low, are there any other dangers or known issues with running RLEC Viewer long term?

These are my settings under RLEC viewer:



As long as the top values (>85° C) are set to 100% would this be safe for long term usage? Or should I wait for the obsidian tool?

 

If i get this correclt from Prema, the tool tends to lose control, so basicially it will suddenly not power fans when it should, causing hardware to kill itself.

Thanks to @ John@OBSIDIAN-PC I'm already working on my own Fan control software since I do not plan on using something that can lose control.

 

That 80-85C 100-60 could set up a very annoying yoyo effect

I would wait for obsidian's tool, I'm sure that would have a supervisor process to ensure safety.

 

John, I'd just like to draw your attention to the fact that the models with the Max-Q GPU versions have an additional Max-Q profile in the CCC.

 

lol yeah, you'd think. Except my temps never get up that high. Delid + Undervolt + Noctua NT-H1 + Underclock. Also only a single 1070.

Thanks Danishblunt, I gathered as much from Prema's post as well, I thought I might as well ask. I don't quite understand how they would "lose control" but I'll defer to Prema's wisdom and stay clear.

It's a real shame, this fan profile made my system a great deal quieter. @Danishblunt Any plans to release your fan control software publicly once complete?... These fans are killing me.

 

Sadly it will be very specific to my system, which will make it pretty much incompatible with everyone elses system, since I have a very special fan setup. Just wait until john finishes his fan software instead.

 

Buying a Clevo system at launch is usually a bad idea because the first EC version tends to have a horrible fan curve out of the box. The P950HP6 had a terrible fan curve at launch (see htwingnut's review) but when I bought it 5 months later, the laptop was pretty much silent at idle or when web browsing (BIOS 1.05.08, EC 1.05.08). Most major OEMs seem to be able to release laptops with decent fan curves at launch, so why can't Clevo do the same?

 

Should have an alpha until the weekend

Sent from my MI Note 2 using Tapatalk

 

Will the alpha be public? I'd like to try it myself to see if its any good or not. I do have a 3fan system (3 seperate fan drivers).

 

The current version is not intended to be "good" it's just a playground to test code.
The final version will have to be good, otherwise we won't sell it
I will make a public alpha (test at your own risk).

Sent from my MI Note 2 using Tapatalk

 

Regarding the FanControl app, does your company accept future firstborns as a payment method?

 

Hahaha
Well you are making it sound like it's going to be expensive....

Sent from my MI Note 2 using Tapatalk

 

Even if its test at our own risk, do you think your alpha should be safer than the RLECViewer posted at the start of this thread?

 

How would he know?? It's an alpha, that's pre beta. As far as he's concerned it's probably worse than RLECViewer.

If it would work without issues perfecly then that would be close to a miracle. Even a beta is supposed to be buggy and the last stage before the final release.

Don't get your hopes up 2 high. I'm still excited to see it and test it.

 

I had the same thought

 

It's not like much can go wrong... Worst case scenario app crashes at a locked manual fan speed.
Fn+1 twice and your back at automatic fan profile.

Someone testing Alpha stuff would surely, at least, be able to see when the app crashes.

Sent from my MI Note 2 using Tapatalk

 

Worst case scenario app crashes at a VERY LOW locked manual fan speed.

Btw. did you read my post about laptops with Max-Q GPUs?
http://forum.notebookreview.com/thr...clevo-fan-control.818858/page-4#post-10764729

 

I'm a bit more concerned because this is my brother's computer. He's not as tech savvy as I am and he may or may not notice his fans failing to spin up when he's rendering video in Adobe Premiere.
I'll probably end up waiting till it's in a "beta" stage before I install it on his rig. He and his wife will just have to deal with hurricane-level fan speeds until then.

 

I did, but no sure what's a maxq fan profile...

Sent from my MI Note 2 using Tapatalk